Dynamic reconfiguration of applications on a multi-processor embedded system

ABSTRACT

A multiprocessor system and method for swapping applications executing on the multiprocessor system are disclosed. The plurality of applications may include a first application and a plurality of other applications. The first application may be dynamically swapped with a second application. The swapping may be performed without stopping the plurality of other applications. The plurality of other applications may continue to execute during the swapping to perform a real-time operation and process real-time data. After the swapping, the plurality of other applications may continue to execute with the second application, and at least a subset of the plurality of other applications may communicate with the second application to perform the real time operation and process the real time data.

BACKGROUND

1. Technical Field

This invention relates to multi-processor systems, and more particularlyto dynamic reconfiguration of software applications executing on amulti-processor system (MPS).

2. Description of the Related Art

An embedded system may be described as a computer system designed forspecific functions, often with real-time computing constraints.Physically, embedded systems range from portable consumer electronicdevices, such as video and/or audio devices, to large stationaryinstallations such as traffic lights, factory controllers, and largelycomplex systems such as hybrid vehicles and avionics. Embedded systemsmay receive input signals and process the signals in real time toperform a specific real-time operation. Embedded systems may instead (orin addition) perform real time processing and generate an output signal.

The processing performed by an embedded system may be implemented indifferent ways. Some devices use field programmable gate arrays (FPGAs)or other programmable logic devices. FPGAs are a means of implementingcomplex systems without using a stored imperative software programmingapproach. Instead, these devices are configured using a hardwaredescription language, such as VHDL or Verilog, which enables the user todescribe an interconnected set of electrical components. The FPGArealizes this interconnected design by programming fuses or settingconfiguration memory locations when the chip is being initialized.

An embedded system may also be implemented with one or more processorsor digital signal processing (DSP) engines. For example, traditionalcoarse-grained programmable embedded systems may have a small number ofprocessors or DSP engines, such as two or four processor cores as wellas fixed or programmable application-specific logical functions. Thesesystems usually have large data and instruction memories or utilizevirtual memory schemes to extend the range of data and instructionmemories that can be addressed.

In some cases it may be desirable to re-program an embedded system atrun-time, e.g., where the re-programming occurs without stopping thesystem. However, both FPGA-based and traditional processor-basedembedded systems have drawbacks that make such re-programmingproblematic. For example, although some FPGA devices may have limitedcapabilities for reconfiguring a specific physical region of the FPGAduring run-time, it is generally difficult to dynamically re-program anFPGA to perform a different application at run-time. For example, theFPGA re-configurability may not be on a logical (or application) basis,but on the basis of what part of the logical design is mapped to aparticular physical part of the chip. Much effort could be expended toalign the logical and physical mapping of a design on an FPGA, but itwould likely cause the implementation to be very inefficient.

In traditional processor-based systems, processing power may be sharedamong different applications through the well-known technique ofmultitasking. In this approach, two or more applications can run at thesame time on the same processor in an interleaved fashion. The processordynamically manages the state of multiple applications. However, thiscan incur a performance penalty and inject a non-deterministic timedelay that may not be acceptable for a real-time embedded system.

It may thus be desirable to provide a real-time embedded system whichoffers an improved ability to perform re-programming of the system atrun-time, e.g., by dynamically swapping applications without stoppingthe system from executing.

SUMMARY

Various embodiments are disclosed of a multiprocessor system and anassociated method for swapping applications executing on themultiprocessor system. The multiprocessor system may include a pluralityof processors and a plurality of memories interspersed among theprocessors. A plurality of applications may be loaded on themultiprocessor system. Loading the applications may include distributinginstructions and data from the plurality of applications among differentrespective ones of the plurality of memories for execution by associatedprocessors. The plurality of applications may be executed on themultiprocessor system. In some embodiments the plurality of applicationsmay execute together and communicate with each other to perform areal-time operation. For example, the plurality of applications mayprocess the real time data. The real-time operation may perform at leastone of input or output with real time data.

The plurality of applications may include a first application and aplurality of other applications. According to some embodiments, thefirst application may be swapped with a second application, wherein thesecond application may not be one of the plurality of applications thatwas previously loaded and executing on the multiprocessor system. Theswapping may be performed without stopping the plurality of otherapplications. In other words, the plurality of other applications maycontinue to execute during the swapping to perform the real timeoperation and process the real time data. After the swapping, theplurality of other applications may continue to execute with the secondapplication, and at least a subset of the plurality of otherapplications may communicate with the second application to perform thereal time operation and process the real time data. The plurality ofother applications may not be aware that the swapping is occurring.

Prior to the swapping, the first application may execute on a firstsubset of the plurality of processors. In some embodiments, the swappingmay include stopping the first application on the first subset of theplurality of processors, decoupling the first application from one ormore external resources that are external to the multiprocessor system,and optionally saving the state of the first application. The swappingmay further include, prior to swapping in the second application,resetting the first subset of the plurality of processors to place thefirst subset of the plurality of processors in a known state. Theswapping may further include decoupling communication of the firstapplication with one or more of the other applications.

The swapping may then involve loading the second application intomemories associated with the first subset of the plurality ofprocessors. After loading the second application, the second applicationmay be coupled to one or more external resources, which may be the sameone or more external resources to which the first application waspreviously coupled, or may be different external resources. After thesecond application has been loaded, the swapping may further includecoupling communication of the second application with one or more of theother applications, which may be the same applications with which thefirst application previously communicated, or may be differentapplications.

In some embodiments, one or more first buffer memories may be coupledbetween the first subset of the plurality of processors and other onesof the plurality of processors. Decoupling communication of the firstapplication may include controlling the one or more first buffermemories to enable the decoupling, e.g., by altering communicationperformed by a first buffer memory to and/or from the first application.

In some embodiments the first application may be on a downstream side ofthe first buffer memory, and altering the communication performed by thefirst buffer memory may include discontinuing the first buffer memoryfrom accepting data from a sending application during the swapping. Insome embodiments the sending application may stall in response to thefirst buffer memory discontinuing accepting data from the sendingapplication. In other embodiments the altering may include configuringthe first buffer memory to continue accepting data from the sendingapplication during the swapping and to overwrite previously stored andunsent data.

In other embodiments the first application may be on an upstream side ofthe first buffer memory, and altering the communication performed by thefirst buffer memory may include discontinuing the first buffer memoryfrom forwarding data to a receiving application during the swapping. Insome embodiments the first buffer memory may be discontinued fromforwarding data to the receiving application once there is no moreincoming data from the first application. In other embodiments thealtering may include configuring the first buffer memory to repeatedlysend its data to a receiving application two or more times during theswapping, e.g., data that was previously received from the firstapplication and stored in the first buffer memory. Thus, the same datamay be repeatedly sent to the receiving application during the swapping.

In some embodiments the first application may communicate structureddata elements via a first buffer memory. Each data element may have abeginning boundary and an ending boundary. The first buffer memory mayreceive a request to discontinue data communication after transmissionof a first data element has been initiated. In some embodiments thefirst buffer memory may continue transmission of the first data elementup to the ending boundary of the first data element.

When the second application is swapped in, the second application may becoupled to the application(s) with which it communicates by configuringone or more of the buffer memories. For example, if the secondapplication communicates with the same other application(s) as the firstapplication then the second application may be coupled to these otherapplication(s) by controlling the same one or more first buffer memoriesinvolved in decoupling the first application from the otherapplication(s).

For example, the first application may have been on the downstream sidefrom a given buffer memory, and the buffer memory may have beendiscontinued from accepting data from a sending application when thefirst application was swapped out. When the second application isswapped in, the buffer memory may be placed back in a mode of acceptingdata. Thus, when the execution of the second application is started, thedata sent by the sending application may now be sent to the secondapplication instead of the first application which previously receiveddata from the sending application.

As another example, the first application may have been on the upstreamside from a given buffer memory, and the buffer memory may have beendiscontinued from forwarding data to a receiving application when thefirst application was swapped out. When the second application isswapped in, the buffer memory may be placed back in a mode of forwardingdata. Thus, when the execution of the second application is started, thereceiving application may now receive data from the second applicationinstead of the first application that previously sent data to thereceiving application.

The second application may execute on the same subset of processors ofthe multiprocessor system that were previously used to execute the firstapplication, or may execute on a different subset of processors, or on acombination of same and different processors. The swapping may includeloading program instructions and/or data of the second application intoone or more memories associated with the subset of processors thatexecute the second application. In some embodiments the secondapplication may be loaded into the one or more memories from an externalmemory device, such as a RAM device, flash memory device, or othermemory device that is external to the multiprocessor system. In otherembodiments the second application may be loaded into the one or morememories from an instruction stream transmitted by an external processoroutside the multiprocessor system.

Loading the program instructions and data of the second application intothe one or more memories may include sending the instructions and datathrough the multiprocessor system along two or more swapping routes(communication routes are one means of physically implementing thecommunication in a multiprocessor system). Each of the swapping routesmay be associated with a particular memory and may be used to loadinstructions/data into that memory. In some embodiments the two or moreswapping routes may share a first part in common, referred to as thetrunk part of the swapping routes. The trunk part may include a routefrom an I/O port of the multiprocessor system to an endpoint within themultiprocessor system. The second parts of the swapping routes mayconnect the endpoint of the trunk route to the target memory devicesused by the second application.

In some embodiments the first application may be swapped with the secondapplication in response to receiving information from one of the otherapplications executing on the multiprocessor system, e.g., where theinformation indicates that the first application should be swapped out.In other embodiments the swapping may include swapping out the firstapplication in response to receiving an external signal indicating thatthe first application should be swapped out. The external signal may bereceived from outside the multiprocessor system. For example, in someembodiments the external signal may be received from a system controllerprogram that executes on a processor external to the multiprocessorsystem.

In some embodiments, a master task or management task may be executed onthe multiprocessor system along with the plurality of applications. Themanagement task may execute on one or more of the processors of themultiprocessor system, and may be configured to manage the swapping ofthe first application with the second application.

In some embodiments the second application may include a plurality ofexecutable tasks, and swapping the first application with the secondapplication may include configuring each of the tasks to be executed bya different processor of the multiprocessor system.

In some embodiments, swapping the first application with the secondapplication may include simultaneously transmitting two or moreinstruction streams to the multiprocessor system from two or more sourcememory devices external to the multiprocessor system. Each instructionstream may include program instructions of the second application.

In some embodiments the swapping may include swapping the firstapplication with a plurality of second applications simultaneously. Theplurality of second applications may be simultaneously loaded into themultiprocessor system from different source memory devices.

In further embodiments, program instructions may be stored on a computerreadable memory medium. The program instructions may be executable by amultiprocessor system to load a plurality of applications on themultiprocessor system. The multiprocessor system may include a pluralityof processors and a plurality of memories interspersed among theprocessors. The loading may include distributing instructions and datafrom the plurality of applications among different respective ones ofthe plurality of memories for execution by associated processors.

The program instructions may be further executable by the multiprocessorsystem to initiate execution of the plurality of applications on themultiprocessor system. The plurality of applications may executetogether and communicate with each other to perform a real timeoperation. The real time operation may perform at least one of input oroutput with real time data. The plurality of applications may processthe real time data.

The plurality of applications may include a first application and aplurality of other applications. The program instructions may be furtherexecutable by the multiprocessor system to swap the first applicationwith a second application, where the second application is not one ofthe plurality of applications that was previously loaded and executingon the multiprocessor system. The swapping may be performed withoutstopping the plurality of other applications. In other words, theplurality of other applications may continue to execute during theswapping to perform the real time operation and process the real timedata. After the swapping, the plurality of other applications maycontinue to execute with the second application. At least a subset ofthe plurality of other applications may communicate with the secondapplication to perform the real time operation and process the real timedata.

According to some embodiments, a multiprocessor system may include: aplurality of processors; a plurality of memories interspersed among theprocessors; and a communication fabric interconnecting the plurality ofprocessors and the plurality of memories interspersed among theprocessors. The communication fabric may include a plurality of buffermemories interspersed among at least a subset of the plurality ofprocessors. The plurality of buffer memories may be configurable tocommunicate data between applications executing in the multiprocessorsystem. During execution of a plurality of applications on themultiprocessor system to perform a real time operation that includesreceipt and/or transmission of real time data and processing of the realtime data, the plurality of buffer memories may be configurable to breakand restore connections between active applications during swapping of afirst application with a second application.

In some embodiments the multiprocessor system may further include aplurality of data memory routers (DMRs) coupled between the plurality ofprocessors. The DMRs may include the plurality of memories interspersedamong the processors.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an example video camera;

FIG. 1B illustrates an embedded system that may be included in orcoupled to the video camera, where the embedded system utilizes amultiprocessor system (MPS) configured with swappable applications;

FIG. 2A illustrates an exemplary cellular phone;

FIGS. 2B and 2C illustrate an MPS used in the phone, where the MPS isconfigured with swappable applications;

FIG. 3A illustrates a wireless transmitter/receiver device;

FIG. 3B illustrates a communication algorithm that may be performed bythe wireless device, where the communication algorithm is implementedusing swappable applications that execute on an MPS;

FIGS. 4-6 illustrate an example of a HyperX™ architecture for an MPSaccording to one embodiment;

FIGS. 7-12 illustrate an example trace of an algorithm executing on anMPS according to one embodiment;

FIG. 13 illustrates an example of an MPS on which a plurality ofapplications are executing;

FIG. 14 illustrates the MPS of FIG. 13 after an application has beenswapped out, and another application has been swapped in to take itsplace;

FIG. 15 illustrates the MPS of FIG. 13 after three applications havebeen replaced with two other applications;

FIG. 16 illustrates an embodiment in which a master task is triggered toinitiate application swapping by an application that executes internallyin the MPS;

FIG. 17 illustrates a different embodiment in which the master task istriggered to initiate application swapping by a system controllerprogram that executes on a general-purpose processor (GPP) locatedoutside of the MPS;

FIG. 18 illustrates an embodiment in which the master task executes onthe external GPP along with the system controller;

FIG. 19 illustrates resources involved in swapping in an applicationfrom an external memory device;

FIG. 20 illustrates an alternative embodiment in which application codeis loaded into the MPS by sending an instruction and data stream from anexternal processor to the MPS;

FIG. 21 illustrates an embodiment in which two applications are swappedin to an MPS simultaneously from two different external RAM devices;

FIG. 22 illustrates a life cycle of swapping an application in and backout;

FIG. 23 illustrates a life cycle of swapping a simple application in andback out;

FIG. 24 illustrates a set of software tools for generating theexecutable software code needed to implement application swapping;

FIG. 25 illustrates a transition from one application configuration onan MPS to another application configuration on the MPS;

FIG. 26 illustrates a development workflow that may be used during thedevelopment phase of the system to construct sets of applications thatare mutually non-interfering;

FIG. 27 illustrates an example in which a plurality of swapping routesare being used to swap in an application; and

FIG. 28 illustrates an example in which a swappable applicationcommunicates with other applications by passing data via isolators.

While the disclosure is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to limit the disclosure to theparticular form illustrated, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present disclosure as defined by the appendedclaims. The headings used herein are for organizational purposes onlyand are not meant to be used to limit the scope of the description. Asused throughout this application, the word “may” is used in a permissivesense (i.e., meaning having the potential to), rather than the mandatorysense (i.e., meaning must). Similarly, the words “include,” “including,”and “includes” mean including, but not limited to.

Various units, circuits, or other components may be described as“configured to” perform a task or tasks. In such contexts, “configuredto” is a broad recitation of structure generally meaning “havingcircuitry that” performs the task or tasks during operation. As such,the unit/circuit/component can be configured to perform the task evenwhen the unit/circuit/component is not currently on. In general, thecircuitry that forms the structure corresponding to “configured to” mayinclude hardware circuits. Similarly, various units/circuits/componentsmay be described as performing a task or tasks, for convenience in thedescription. Such descriptions should be interpreted as including thephrase “configured to.” Reciting a unit/circuit/component that isconfigured to perform one or more tasks is expressly intended not toinvoke 35 U.S.C. §112, paragraph six interpretation for thatunit/circuit/component. More generally, the recitation of any element isexpressly intended not to invoke 35 U.S.C. §112, paragraph sixinterpretation for that element unless the language “means for” or “stepfor” is specifically recited.

DETAILED DESCRIPTION OF EMBODIMENTS

Incorporation by Reference

U.S. Pat. No. 7,415,594 titled “Processing System With InterspersedStall Propagating Processors And Communication Elements” whose inventorsare Michael B. Doerr, William H. Hallidy, David A. Gibson, and Craig M.Chase is hereby incorporated by reference in its entirety as thoughfully and completely set forth herein.

U.S. patent application Ser. No. 13/274,138, titled “DisablingCommunication in a Multiprocessor System”, filed Oct. 14, 2011, whoseinventors are Michael B. Doerr, Carl S. Dobbs, Michael B. Solka, MichaelR Trocino, and David A. Gibson is hereby incorporated by reference inits entirety as though fully and completely set forth herein.

TERMS

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, internet appliance, personal digitalassistant (PDA), grid computing system, or other device or combinationsof devices. In general, the term “computer system” can be broadlydefined to encompass any device (or combination of devices) having atleast one processor that executes instructions from a memory medium.

Software Application—the term “software application” (also referred toherein as just an “application”) is intended to have the full breadth ofits ordinary meaning, and includes any type of program instructions,code, script and/or data, or combinations thereof, that may be stored inone or more memories and executed by one or more processors. Exemplarysoftware applications include programs written in text-based programminglanguages, such as C, C++, FORTRAN, Java™, assembly language, etc.;graphical programs (programs written in graphical programminglanguages); assembly language programs; programs that have been compiledto machine language; scripts; and other types of executable software.

An application may execute on one or more processors of an MPS and mayread data from and/or write data to one or more of the local memories ofthe MPS. An application may include one or more computational tasks,where each task typically runs on a single processor of the MPS and mayshare the processor with one or more tasks from one or moreapplications. The application may perform a particular function oroperation. If the application includes more than one task, the tasks maycommunicate with each other to perform the function or operation.

The MPS may simultaneously execute a plurality of applications, e.g.,where the applications execute in parallel with each other. Theapplications may communicate with each other, and the respectivefunctions or operations performed by the applications may build uponeach other to perform a larger or higher-level function or operation.

Automatically—refers to an action or operation performed by a computersystem (e.g., software executed by the computer system) or device (e.g.,circuitry, programmable hardware elements, ASICs, etc.), without userinput directly specifying or performing the action or operation. Thusthe term “automatically” is in contrast to an operation being manuallyperformed or specified by the user, where the user provides input todirectly perform the operation. An automatic procedure may be initiatedby input provided by the user, but the subsequent actions that areperformed “automatically” are not specified by the user, i.e., are notperformed “manually”, where the user specifies each action to perform.For example, a user filling out an electronic form by selecting eachfield and providing input specifying information (e.g., by typinginformation, selecting check boxes, radio selections, etc.) is fillingout the form manually, even though the computer system must update theform in response to the user actions. The form may be automaticallyfilled out by the computer system where the computer system (e.g.,software executing on the computer system) analyzes the fields of theform and fills in the form without any user input specifying the answersto the fields. As indicated above, the user may invoke the automaticfilling of the form, but is not involved in the actual filling of theform (e.g., the user is not manually specifying answers to fields butrather they are being automatically completed). The presentspecification provides various examples of operations beingautomatically performed in response to actions the user has taken.

Detailed Description

Various embodiments of a multi-processor system (MPS) and an associatedmethod for dynamically swapping applications executing on the MPS aredescribed. A multi-processor system (MPS) may be defined as a systemthat includes a plurality of processing elements (PEs). A MPS may have aplurality of memories interspersed among the PEs, or alternatively mayhave a single shared memory. As used herein, the term “processingelement” refers to a processor or CPU (central processing unit),microprocessor, or a processor core. Although an MPS may include anynumber of two or more PEs, it is noted that some MPSs may includesignificantly more PEs than a traditional computer system whichtypically includes only one general purpose processor (GPP), or a fewGPPs. For example, some MPSs may include 4, 8, 16, 32, or 64 PEs (otherexamples include, e.g., dozens, hundreds, or even thousands of PEs). Insome embodiments, PEs suitable for large MPSs may be more energyefficient than general purpose processors used by traditional computersystems because of their special construction for the purpose of lowpower consumption.

MPS may also include an interconnection network (IN) that interconnectsthe PEs and/or memories. The PEs and memories may be interconnected inone, two, three, or more dimensions, including circular dimensions(e.g., loops or rings). A higher-dimensioned MPS can be mapped ontofabrication media with fewer dimensions. For example, an MPS with theshape of a four dimensional (4D) hypercube can be mapped onto a 3D stackof silicon integrated circuit (IC) chips, or onto a single 2D chip, oreven a 1D line of computational units. Also, low-dimensional MPSs can bemapped to higher dimensional media. For example, a 1D line ofcomputation units can be laid out in a serpentine shape onto the 2Dplane of an IC chip, or coiled into a 3D stack of chips. An MPS mayinclude multiple types of computational units and interspersedarrangements of processors and memory. Also included in the broad senseof an MPS is a hierarchy or nested arrangement of MPSs, especially anMPS composed of interconnected IC chips where the IC chips contain oneor more MPSs which may also have deeper hierarchal structure.

As used herein, the term MPS covers both relatively homogeneous sets ofprocessors, as well as heterogeneous collections of general purpose, andspecialized processors that are integrated on so-called “platform IC”chips. Platform IC chips may contain from a few to many processors,typically interconnected with shared memory and perhaps an on-chipnetwork. There may or may not be a difference between a MPS and a“platform IC” chip. However, a “platform IC” chip may be marketed toaddress specific technical requirements in a specific vertical market.

In general, the memory for an MPS may be organized in a hierarchy withfast memory at the top and slower but higher capacity memory at eachstep down the hierarchy. In an MPS, supporting memories at the top ofthe hierarchy may be located nearby each PE. Each supporting memory maybe specialized to hold only instructions or only data. Supporting memoryfor a particular PE may be private to that PE or shared with other PEs.

Further down the memory hierarchy there may be a larger shared memory,such as a semiconductor synchronous dynamic random access memory (SDRAM)with a bit capacity many times larger than that of the supporting memoryadjacent to each PE. Further down the memory hierarchy there may beother types of memory, such as flash memory, magnetic disks, and opticaldisks.

The MPS may be programmed with software applications to accomplishspecific operations. Each of the applications may be executed by one ormore of the PEs in the MPS. Oftentimes, multiple applications mayexecute concurrently with each other on the MPS. The applications mayexecute together and communicate with each other to perform a real-timeoperation. The real-time operation may perform input and/or output withreal-time data. For example, the MPS may receive real-time data via aninput signal. One or more of the applications may process the inputsignal, and possibly produce an output signal with modified oradditional real-time data based on the processing.

At some point during the execution of the system, it could be determinedthat a particular application may not need to execute. For example, thatapplication may become idle and remain idle for a long period of time,or that application's priority could be lower than another applicationthat is waiting to run, or another application could need access tospecific resources that are being used by the application. It thus maybe advantageous to stop the execution of the running application andallow another application to use the newly available processorresources. This is referred to herein as “swapping out” the applicationthat was previously running, and “swapping in” the other application.

Embedded systems usually need to remain active and continue to function,and generally cannot be arbitrarily stopped. An example is a system thatcontrols a critical safety device, where stopping the system mightproduce an unsafe situation. As another example, where the embeddedsystem is processing video and/or audio for presentation to a user ortransmission, stopping the embedded system may cause undesirableartifacts in the media data. In an embedded system, the process by whichapplications are stopped and started may thus need to be handledcarefully. The swapping method described herein may enable applicationsto be swapped without stopping the system. For example, applicationsother than the applications being swapping in/out that are currentlyexecuting on the MPS may continue to execute while the swapping occurs.In addition, the swapping method may also enable the swapping to be donequickly to ensure that the system is complete and remains functioningsmoothly.

The swapping method described herein may account for resourcelimitations of particular MPSs. Such limitations may include the amountof instruction memory available for each PE, the amount of data memoryavailable for each PE, the bandwidth of communication between PEs, thebandwidth of communication between the PEs and external memory, etc. Forexample, an MPS in which the PEs have limited instruction memory mayrequire new instructions to be moved into instruction memory fromexternal storage in order to initialize a new application. The swappingmethod may thus be sensitive to a resource-limited MPS. As described indetail below, the swapping method may enable a first application (orfirst set of applications) to be safely stopped and its processingresources freed for other uses, and further enable a second application(or second set of applications) to be quickly and safely started runningon available processing resources.

During the swapping process, other applications executing in theembedded system may continue to operate, and may be unaware that theswapping is being performed. Furthermore, the applications that areswapped in or out may not be “swapping aware” themselves. In otherwords, the swappable applications may not need to be speciallyconstructed. This may advantageously enable the swappable applicationsto be easily constructed, e.g., by writing or developing them as normalapplications in the conventional manner without the need to includespecial program logic to implement the swapping. The program code thatimplements the swapping may be implemented in other components externalto the swappable applications themselves.

FIGS. 1A-3B Examples of Dynamically Re-Configurable MPSs in EmbeddedSystems

FIGS. 1A-3B illustrate several examples of re-configurable MPSs, e.g.,where the MPSs are configured to dynamically swap applications in andout according to the techniques described herein. Each MPS may be partof an embedded system that operates in a device to perform a real-timeoperation. It is noted that FIGS. 1A-3B are examples only, and any ofvarious other types of embedded systems may use the methods describedherein.

FIG. 1A illustrates a video camera 201, and FIG. 1B illustrates anembedded system 202 that may be included in or coupled to the videocamera 201. As shown in FIG. 2B, the embedded system 202 includes acamera link interface 204 that receives a video signal from the videocamera 201, and passes it to the MPS 203. In this example, the MPS 203includes a base system 208 that receives the raw video stream andperforms basic processing, such as de-mosaicing and color spaceconversion to transform the raw camera data into data that is consumableby the downstream filters. The base system 208 may provide thetransformed data to one or more image processing applications 209. Theimage processing applications may include at least two applications,where each one is configured to filter or otherwise process the videodata in any of various ways. The image processing applications may bedynamically swapped in and out to change the way the video signal isprocessed. As one example, the system may initially execute an edgefilter application that performs an edge filtering algorithm on thesignal. In response to user input or other conditions, the edge filterapplication may be dynamically swapped with a median filter applicationthat performs a median filtering algorithm on the signal. The result ofthe current image processing application may be combined with theoriginal data produced by the base system 208 by the “combine videostreams” block 207, e.g., in a split-screen display. The combined signalmay then pass via the digital video interface (DVI) block 206 to the DVIinterface 210, which is coupled to a display device. Thus, the result ofswapping the edge filter application and the median filter applicationmay be viewed on the display device in real time. The video stream mayalso be passed to the general-purpose processor (GPP) 211. A programexecuting on the GPP 211 may also provide control signals to the MPS todirect which filter should execute on MPS 203.

FIG. 2A illustrates a cellular phone 215, and FIGS. 2B and 2C illustratean MPS 216 used in the phone. In the configuration of the MPS shown inFIG. 2B, the MPS is currently executing a cellular search application218. The phone uses the Long Term Evolution (LTE) 4G cellular telecomradio interface technical standard. In accordance with the LTE standard,the phone first registers with a local cellular base station using thecellular search application 218. Once registered, the cellular searchapplication 218 is no longer needed. Thus, the cellular searchapplication 218 may be dynamically replaced with a differentapplication, e.g., the shared-link data processing application 219 shownin FIG. 2C. The front end application 217 performs re-sampling andup/down conversion, and it remains executing on the MPS while thisswapping occurs. If the MPS is sufficiently large (e.g., 100+processors) then a portion of the cellular search and shared-link dataprocessing applications may remain loaded at all times, e.g., instead ofentirely loading and unloading them when they are swapped.

In this example, the desired time interval for cut over from thecellular search application to the shared-link data processingapplication, and the reverse in the event of a need to re-register, is 4ms. If the cut-over is too slow the media access controller 221 revertsto re-registration. The cellular search application performs many CRCcomputations in parallel and upon finding a true signal the phone locksonto that one signal. There is a short interval while the media accesscontroller completes the registration process and requests data slots inthe shared link. The media access controller is designed to look aheadof the currently transmitted data in order to properly reserve slots.Typically it looks ahead by 4 subframes, or about 4 milliseconds, andthus, this is the desired interval for cut-over to the shared-link dataprocessing application.

FIG. 3A illustrates a wireless transmitter/receiver device 230. Device230 may instead be a receiver only device, such as a radio. FIG. 3Billustrates a communication algorithm that may be performed by thewireless device 230. The top part illustrates the transmission portion231 of the algorithm, and the bottom part illustrates the receiveportion 232 of the algorithm. The modulator bank 235 performs amodulation algorithm, and the demodulator bank 236 performs ade-modulation algorithm. The modulator bank 235 and possibly other partsof the transmission portion 231 of the algorithm may be implemented on aMPS that uses a plurality of modulator applications. At any given time,only one of the modulator applications may be loaded and executing. TheMPS may be configured to dynamically swap the currently loaded modulatorapplication for a different one in order to change the particularmodulation algorithm in use. Different de-modulation applications may beswapped in and out in a similar manner to dynamically change thede-modulation algorithm performed by the demodulator bank 236. Portionsof the communication algorithm not necessary to understand the presentdisclosure are omitted from this description.

It is noted that FIGS. 1A-3B are presented as examples of devices inwhich an MPS that is configured to dynamically swap softwareapplications may be used. In various embodiments an MPS such asdescribed herein may be used in any kind of device or system. Also, theapplications that are swapped in and out may be any kind of softwareapplications, e.g., applications that process real-time data in any ofvarious ways, or perform any of various other kinds of functions toimplement a real-time operation or other operation performed by a deviceor system.

FIGS. 4-12 Example MPS Architecture

In various embodiments, the application swapping techniques describedherein may be utilized on any of various kinds of MPSs. The MPS may haveany desired architecture. FIGS. 4-6 illustrate an example architecturefor an MPS according to one embodiment. This MPS architecture is anexample of HyperX™ architecture disclosed in U.S. Pat. No. 7,415,594.This architecture may be suitable to implement a programmable, verylow-power, low-cost many-processor embedded computer system (hereembodied as a single integrated-circuit chip) with the capability tosimultaneously run many applications. The following description of theHyperX™ architecture is merely an example, and any of various other MPSarchitectures may be used, as desired.

In the embodiment illustrated in FIG. 4, the MPS 10 includes a pluralityof processing elements (PEs) represented as squares. The MPS alsoinclude a plurality of data memory routers (DMRs) represented ascircles. The DMRs act as supporting memories for the adjacent PEs, aswell communication routers or switch nodes. Lines between the DMRsillustrate DMR-to-DMR communication channels or links that implement aninterconnection network (IN). The DMRs may be used with the links toform communication pathways between PEs, as well as between PEs and I/Oports that couple the MPS to external devices. At each PE, anyinformation communicated may be buffered in a memory in an adjacent DMR.As used herein, a PE may also be referred to as a PE node, and a DMR mayalso be referred to as a DMR node. A DMR is also referred to herein as a“configurable communication element”.

The links between DMRs shown in FIGS. 4 and 5 form a rectilinear mesh.However, many other connection schemes are possible and contemplated. Inthe MPS connection scheme illustrated in FIG. 5, each PE is connected tofour neighbor DMRs, while each DMR is connected to four neighbor PEs aswell as four neighbor DMRs. Other connection schemes are also envisionedto support higher dimensionality INs, such as the use of six DMR-to-DMRlinks per DMR to support a three dimensional rectilinear mesh, or eightlinks per DMR to support the four diagonal directions in addition to thenorth, east, south, and west directions. Links need not be limited tophysically nearest neighbors.

MPS 20 with chip I/O's may be used in any of various systems andapplications where general purpose microprocessors, DSPs, FPGAs, orASICs are currently used. For example, the processing systemsillustrated in FIGS. 4 and 5 may be used in any of various types ofcomputer systems, digital signal processors (DSP) or other devices thatrequire computation.

HyperX Hardware Fabric

In one embodiment of the HyperX™ architecture, a multi-processor arraymay be composed of a unit-based hardware fabric (mesh), wherein eachunit is referred to as a HyperSlice. The hardware fabric may be formedby arranging the units on a grid and interconnecting adjacent units.Each HyperSlice unit may include one or more data memory and routers(DMRs) and one or more processing elements (PEs).

In U.S. Pat. No. 7,415,594, a DMR may be referred to as a dynamicallyconfigurable communication (DCC) element, and a PE may be referred to asa dynamically configurable processing (DCP) element. The DMR may providesupporting memory for its neighboring PEs, and routers and links for theinterconnection network (IN). Dynamically configurable in this contextmeans those hardware resources (PE, DMR links, and DMR memory) may bere-allocated while application software is running. This can be achievedby dividing the application software into a hierarchy of smaller tasksand communication messages. These tasks and messages may be assigned toresources and executed concurrently (or serially if required). As tasksand messages are completed they may be re-executed or be replaced byother tasks and messages to form a new configuration of the applicationsoftware. The capability to change configuration “on the fly” supportsthe flexibility to make more efficient use of finite resources, and tobetter adapt to changing external demands, amongst others.

The HyperX™ hardware fabric has a primary IN (PIN) that operatesindependently and transparently to the processing elements, and mayprovide on-demand bandwidth through an ensemble of real-timeprogrammable and adaptable communication pathways (which may be referredto as routes or paths) between HyperSlices supporting arbitrarycommunication network topologies. Coordinated groups of HyperSlices maybe formed and reformed “on-the-fly” under software control. This abilityto dynamically alter the amount of hardware used to evaluate a functionallows for the optimal application of hardware resources to relieveprocessing bottlenecks. At the edge of the hardware fabric, links mayconnect to circuits specialized for types of memory that are furtherdown the memory hierarchy, or for I/O at the edge of an integratedcircuit (IC) chip.

The interconnected DMRs of the HyperX™ hardware fabric may providenearest-neighbor, regional, and global communication across the chip andfrom chip to chip. Each of these communication modes may physically usethe DMR resources to send data/messages differently depending onlocality of data and software algorithm requirements. A “Quick Port”facility may be provided to support low latency transfer of one or morewords of data from a processor to any network destination. For blocktransfers, Direct Memory Access (DMA) engines within the DMR may beavailable to manage the movement of data across the memory and routingfabric (or communication fabric). For nearest-neighbor communicationbetween PEs, the use of shared memory and registers may be the mostefficient method of data movement. For regional and global datamovement, using the routing fabric (the PIN) may be the most efficientmethod. Communication pathways (or routes) can either be dynamic orstatic. Dynamic routes may be set up for data transfer and torn downupon the completion of the transfer to free up PIN resources for otherroutes and data transfers. Static routes may remain in place throughoutthe program execution and may be primarily used for high priority andcritical communications. The physical location of communication pathwaysand the timing of data transfers across them may be under softwareprogram control. Multiple communication pathways may exist to supportsimultaneous data transfer between any senders and receivers.

Processing Elements (PE)

The architecture of the DMR may allow different interchangeable PEs tobe used in a multi-processor fabric to optimize the system for specificapplications. A HyperX™ multiprocessor system may comprise either aheterogeneous or homogeneous array of PEs. A PE may be a conventionalprocessor, or alternatively a PE may not conform to the conventionaldefinition of a processor. In some embodiments a PE may be a collectionof logic gates serving as a hard-wired processor for certain logicfunctions where programmability is traded off for higher performance,smaller area, and/or lower power.

As illustrated in FIG. 5, PEs in an MPS, such as a HyperX™ MPS, forexample, may be supplied with parallel connections to multiple memoriesby interspersing DMRs between the PEs. Such an arrangement may reducethe time and energy required for a given PE to access memory in a DMRrelative to a segregated (i.e., non-interspersed) arrangement, and maybe referred to herein as an interspersed arrangement.

In the embodiment of FIG. 4, the ratio of PEs to DMRs is roughly 1:1.Different ratios of PEs to DMRs may be possible in various otherembodiments.

A HyperX™ processor architecture may include inherentmulti-dimensionality, but may be implemented physically in a planarrealization. The processor architecture may have high energy-efficientcharacteristics and may also be fundamentally scalable (to large arrays)and reliable—representing both low—power and dependable notions. Aspectsthat enable the processor architecture to achieve high performance mayinclude the streamlined processors, memory-network, and flexible IO. Theprocessing elements (PEs) may be full-fledged DSP/GPPs and based on amemory to memory (cacheless) architecture sustained by a variable widthinstruction word instruction set architecture that may dynamicallyexpand the execution pipeline to maintain throughput whilesimultaneously maximizing use of hardware resources.

Setup of Communication Pathways

FIG. 4 illustrates an embodiment of a HyperX™ system, including anetwork of processing elements (PEs) and Data Memory Routers (DMRs). ThePEs are shown as rectangular blocks and the DMRs are shown as circles.The routing paths between DMRs are shown as dotted lines. Solidtriangles show off-mesh communication and solid bold lines show activedata communication between DMRs. A computational task is shown by itsnumerical identifier and is placed on the PE that is executing it. Adata variable being used for communication is shown by its name and isplaced on the DMR that contains it. In the illustrated embodiment, thetop left PE has been assigned a task with task ID 62, and maycommunicate with other PEs or memory via the respective DMRs adjacent tothe PE, designated by communication path variables t, w, and u. As alsoshown, in this embodiment, an active communication route connects a PEdesignated 71 (e.g., another task ID) to an off-mesh communication pathor port via an adjacent DMR labeled “x.”

Data Memory Router

A block diagram of an example embodiment of DMR hardware structure isillustrated in FIG. 6. In the illustrated embodiment, a central datamemory (DM) is surrounded by an octagonal ring representing a router. Itis noted that the octagonal shapes shown are merely symbolic, and thatactual shapes may be different, e.g., may be rectangular. Surroundingthe DMR are a number of bi-directional arrows representing data paths toother DMRs and PEs. These bidirectional data paths may be implementedwith actual bidirectional transceivers at each end, or as a pair ofunidirectional paths directed oppositely.

Unidirectional arrows between the router and the data memory in FIG. 6represent unidirectional data paths between memory and router. A smallsquare near theses arrows represents a DMA engine, i.e., a DMA reader(DMAR) to support readout from DM, and/or a DMA writer (DMAW) to supportwriting data to DM. A DMAR engine generates address signals for thememory, typically to increment across a buffer, reading data to send outa link to another DMR. Similarly, a DMAW engine generates addresssignals for the memory, typically to increment across a buffer, writingdata that it receives from a link. Each DMA engine is much smaller thana PE and uses less power, so they are attractive to use for reading andwriting of blocks of memory. DMA engines may be configured by PE writesto associated configuration registers in the DM memory space. Writing toa particular address triggers a DMA to start incrementing. When a DMAfinishes incrementing through a block of addresses, it stops—unlessconfigured to continue looping, either indefinitely or for a predefinednumber of loops.

To support high-bandwidth ports in an MPS, such as MPS 20 as illustratedin FIG. 5, the connections or links between ports (PE-to-DMR, orDMR-to-DMR) may be short (i.e., limited to neighbors) and composed ofmany parallel electrically-conductive traces or “wires” or “lines”. Insome embodiments a link may be composed of only a few parallel traces,one trace, or a waveguide.

The PE-to-DMR connections may separate traces for memory addresses fromtraces for data. Traces for data may be connected to transceivers tosupport bidirectional data transfer or separated into one set of tracesto bring write data to memory and another set of traces to bring readdata from memory. The DMR-to-DMR connections may not necessarily haveaddress lines but may have lines to signify special words in the datatransferred, such as control words for message header or messagetermination.

All DMR connections may have additional lines for flow control, Forexample, a line may signal upstream (from destination to source) thatfurther progress of data words is blocked either because there is someother communication path in the way or the destination cannot acceptmore data. Another line may signal downstream (from source todestination) that valid data is ready. Both the upstream and downstreamsignaling may be used to indicate the state of transmitters andreceivers connected to the ends of a link between DMRs, either local(adjacent) DMRs or global (non-adjacent) DMRs. In some MPS embodiments,communication between nodes may be under programmer control.

FIGS. 7-12 illustrate an example trace of an algorithm executing on anMPS. The algorithm is deliberately simple and sparse for illustrativepurposes. The algorithm brings sample data onto the MPS, processes thedata, and then sends the result off the MPS. Then the algorithm startsover at the beginning, and brings the next set of sample data onto themesh.

In FIG. 8, task 62 is reading data from sources external to the MPS andstoring the data in variables “t” and “u”. At the same time, task 62 iscombining variables “t” and “u” and writing the results into variable“w”. Simultaneously, task 71 is bringing data from off-mesh and storingit in variable “x”.

At some later time (FIG. 9), task 62 finishes reading variables “t” and“u” and begins transmitting variable “w” to task 12 where it will befurther processed. Task 12 must wait until variable “w” and variable “x”are both available to begin its next computational task. Once the datais ready, task 12 computes variable “sv” from its inputs “x” and “y”(FIG. 10), where “sv” is a shared variable.

In FIG. 11, shared variable “sv” is acted on by task 5 to producevariable “z”. Since “sv” is shared, there is no explicit communicationbetween task 12 (in FIG. 10) and task 5, but there is synchronizationbetween the tasks. Simultaneously, tasks 62 and 71 start reading thenext data samples from off-mesh (as in FIG. 8).

In FIG. 12, task 5 sends the final result (variable “z”) off the meshwhile tasks 62 and 71 continue to read the next data samples.

FIGS. 13-28—Application Swapping

An MPS may have the capability to simultaneously run many softwareapplications. FIG. 13 illustrates an example of an MPS 300 on which aplurality of applications are executing. In order to execute theapplications, instructions and data from the plurality of applicationsmay be distributed among different memories of the MPS for execution byprocessors associated with the memories. For example, programinstructions and data for one of the applications may be stored in afirst subset of the memories of the MPS. A first subset of theprocessors of the MPS may be coupled to the first subset of the memoriesand may execute the instructions and data for the application.Similarly, program instructions and data for another of the applicationsmay be stored in a second subset of the memories for execution by asecond subset of the processors, and so on.

In some embodiments a given memory of the MPS may be associated with orreserved for a particular processor of the MPS. In other embodiments agiven memory may be shared by more than one processor of the MPS. Insome embodiments the memory or set of memories used by a given processormay be physically located near the processor, e.g., such that theprocessor can directly access the memory without using aninterconnection network or communicating with other routing elements.

In FIG. 13, the relative sizes of the ovals are intended to illustratethe relative amounts of system resources (e.g., the number of processorsand memories) allocated to the applications. For example, theapplication 5C is represented by a large oval indicating that thisapplication uses more of the system's processors than the application 5Awhich is represented by a small oval. Also, the relative placement ofthe ovals within the MPS 300 is intended to illustrate the physicalplacement of the applications on the MPS, e.g., the respective physicalregions of the MPS in which the processors and memories used by eachapplication are located. (In this example, the MPS is illustrated ashaving a two-dimensional layout, but in other embodiments the processorsand memories of the MPS may be arranged according to a different numberof dimensions, e.g., 1D, 3D, 4D, etc.)

The term “application swapping” refers to the process of removing one ormore applications and replacing them with one or more otherapplications. The swapping may occur dynamically while the otherapplications continue to execute. For example, FIG. 14 illustrates theMPS 300 after the application 5E has been swapped out, and theapplication 5K has been swapped in to take its place. The otherapplications 5A, 5B, 5C, 5D, 5F, 5G, 5H, and 5J can continue to executeon the MPS while the swapping between the applications 5E and 5K occurs.Although the application 5K is placed within the MPS in the same generalarea where the application 5E previously executed, the application 5Kmay not necessarily use the exact same processor and memory resources asthe application 5E.

The system may also swap in and/or swap out more than one application ata time. FIG. 15 illustrates an example in which the three applications5E, 5G, and 5H from FIG. 13 have been replaced with the two applications5L and 5J. Thus, the number, shape (in terms of physical placement), andsize (in terms of processor and memory resources used) of the swappedapplications do not have to be the same.

There are a numerous reasons why it may be desirable in variousembodiments to remove one or more applications from a running MPS andreplace it with one or more others. For example, an application mayexecute for a while and then not have anything to do for long stretchesof time. During this time, the application's resources could be used bysome other application, thereby improving the performance of the overallsystem. Another reason is that it might be desirable to change thefunctionality of the MPS by removing one application and replacing itwith another application. For example, the two applications may performthe same general function but in a somewhat different way.

As described in more detail below, application swapping may includeoperations to dynamically load and execute an application, stop arunning application, and clear the resources of a stopped application.These operations may be designed to be performed in such a way thatother applications running on the MPS are not disturbed while theapplication swapping is in process so that the other applications cancontinue executing with their normal operation preserved.

In some embodiments, application swapping may be managed by a specialtask or application referred to herein as a master task or managementtask. The master task may be triggered from either inside or outside theMPS to initiate application swapping. FIG. 16 illustrates an embodimentin which the master task 55 is triggered to initiate applicationswapping by an application 6F that executes internally in the MPS. Forexample, the application 6F may include program logic that triggersapplication swapping in response to various internal state changes thatoccur within the application 6F. FIG. 17 illustrates a differentembodiment in which the master task 55 is triggered to initiateapplication swapping by a system controller program 262 that executes ona general-purpose processor (GPP) 260 located outside of the MPS. Forexample, the system controller 262 may trigger application swapping inresponse to user input or any of various other kinds of triggers orconditions that originate outside the MPS. In some embodiments, themaster task 55 may execute outside of the MPS. For example, FIG. 18illustrates an embodiment in which the master task 55 executes on theexternal GPP 260 along with the system controller 262.

The system controller 262 may be written using a high-level applicationprogramming interface (API). The API may enable the system controller tobe easily ported from one GPP to another by hiding the details of theunderlying control and communication layer.

The master task 55 may receive high level commands from the systemcontroller 262 (or from another application within the MPS), such as“swap application X out” or “swap application Y in,” and in response mayinitiate and manage the requested application swapping.

The default behavior of the master task may be to start and stopapplications as directed by the system controller 262. In somesituations the master task 55 may communicate with a swappableapplication to manage its execution state. For example, the master task55 may request a swappable application to come to a stable state so thatit can be swapped out, or the master task 55 may be notified by theswappable application that it is in a stable state and is ready to beswapped out. This communication can be implemented through an API thatthe swappable application can call to communicate with the master task55, or vice versa.

In various embodiments, as noted above, the MPS may have different formfactors. In some embodiments the MPS may be implemented as an integratedcircuit on a chip. In some embodiments multiple MPS chips may be used inthe system. The chip(s) may be coupled to other hardware devices thatare external to the chip(s), such as one or more off-chip processors(e.g., general-purpose processors) or one or more off-chip memorydevices (e.g., RAM, flash memory, disk drives, or other types of memoryor storage devices) or other hardware devices that are not part of theMPS itself. In some embodiments the off-chip memory may be used whenswapping applications in or out, e.g., to save program data for anapplication being swapped out to a memory device external to the MPS, orto retrieve program instructions and/or data for an application beingswapped in from the external memory device. The external memory devicein which the information for the swapped-out application is stored maybe the same external memory device from which the information for theswapped-in application is retrieved, or may be a different externalmemory device. The ability to swap the instructions and data forapplications to and from external memory devices may be useful for MPSsthat do not have sufficient internal memory resources to store in theirentirety all of the applications that need to be executed on the MPS.

FIG. 19 illustrates resources involved in swapping in an application 8from an external memory device 272, according to one embodiment. In thisexample, the application code 270 may initially be stored in arandom-access memory (RAM) device 272 coupled to (and external to) theMPS 300. The RAM device 272 may include any kind of RAM, such as dynamicRAM (DRAM), synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), staticRAM (SRAM), etc. The application code 270 may be loaded to the MPS fromthe RAM device 272 via an input/output (IO) port 274. The IO port 274may be controlled by a dedicated loader PE 276. From the IO port 274,the application code may be transmitted via one or more swapping routes277 to one or more of the internal memories of the MPS that areassociated with the application 8.

In other embodiments, the application code 270 may be swapped in fromany other kind of external memory device besides a RAM device. Examplesof external memory devices that may be utilized for swapping includeflash memory, magnetic or optical memory, disk drives, solid statedrives, etc. As noted above however, in some embodiments one goal of thesystem may be to perform the swapping as quickly as possible. Thus, thetype of external memory device that is used for the swapping may bechosen to be a fast type of memory device. For example, a DRAM devicemay generally enable the swapping to be performed faster than a flashmemory device or disk drive, and thus may be preferred in someembodiments.

FIG. 20 illustrates an alternative embodiment that may also enable fastswapping. In this example, the GPP 260 may load the application code 270into the MPS by sending an instruction and data stream to the MPS. Thesystem controller program 262 may control the instruction and datastream.

In some embodiments the system controller program 262 may run on the GPP260 in an embedded operating system environment. In some embodiments thesystem controller 262 may be implemented using a subset of the OpenComputing Language (OpenCL) language. The system controller 262 maycommunicate with the MPS through a chip-to-chip communication mechanism,but may be implemented to be independent of the communication mechanism.

The system controller 262 may send commands to the master task 55 eitherdirectly, such as through the MPS chip's serial bus (e.g., via a DebugAccess Port (DAP)), or through a signal port. Since the amount ofcontrol data passing between the system controller 262 and the mastertask 55 will typically be small, communicating through the MPS's serialbus should not significantly affect the swapping performance. The systemcontroller 262 can get data back from the MPS by reading data valuesusing the DAP port. The system does not require a communication pathfrom the MPS to the GPP but could employ one if it is available. Thecommunication protocol between the GPP and the MPS can be implemented inmany different ways depending on the capabilities of the GPP. Forexample, it can be a high-level protocol such as Universal Serial Bus(USB) or Peripheral Component Interconnect Express (PCIe), or it couldbe a simpler connection between a GPP bus and a signal port. In morecomplex protocols such as USB or PCIe, an FPGA device may be usedbetween the GPP and MPS to implement the receive side of the protocol.In some embodiments, a small FPGA device may be used for the simpler GPPbus connection also.

For communication efficiency, in some embodiments the master task 55 mayreside on a PE at a location that has direct access to the MPS's serialbus which is connected to all the other PEs and memories on the MPS.Using the serial bus for communication may be desirable in order toavoid interfering with ongoing data communication in the MPS that occursin the interconnection network. However, any other means ofcommunication between the master task and the rest of the swappablesystem can be used. In some embodiments a particular PE may be reservedfor the master task 55 such that the PE cannot be used for applications.Also, in some embodiments a memory adjacent to the PE may be reservedfor use by the master task 55 for its storage needs.

The instructions and data that define the swappable applications can bestored in any location that is accessible from the MPS. If the MPSincludes sufficient internal memory resources, all the applications canbe stored in local memory devices internal to the MPS. As mentionedabove, in other embodiments the applications can be stored on one ormore external memory devices, such as one or more DRAM devices coupledto the MPS, in the GPP file system and streamed directly to the system,in one or more flash memory devices coupled to the MPS, etc.

The important parameters of the application memory are the storagecapacity and the bandwidth available for moving the instructions ontothe MPS. For example, if one small application is being swapped, a localmemory internal to the MPS could likely be used. For many systems thesize of the internal memory may be limited and the speed of swapping isimportant, so streaming the application instructions directly from theGPP or using the attached DRAM may be necessary. Streaming theinstructions directly from the GPP may be advantageous in hardwaresystems in which there are no DRAMs attached to the system or in systemswhere the DRAMs are supporting heavy data traffic for the applicationsalready running on the system.

In cases where the application instructions are loaded from an externalDRAM coupled to the MPS or streamed from the GPP, an I/O port 274 and anadjacent loader PE 276 that executes a loader task may be reserved forapplication swapping and cannot be used by applications, as shown inFIGS. 19 and 20. In some embodiments, the loader task may manage theapplication instructions and data flowing through the I/O port. Forexample, the instructions and data for swapping an application could bestored in a DRAM device connected to the IO port on the MPS, and theadjacent loader task can be used to pull the application instructionsfrom the proper address in the DRAM and then send the instructionsthrough the routing fabric to the internal MPS memories associated withthe application's PEs.

When using a loader task for I/O port control, the master task maycommunicate with the loader task through a mechanism that will notdisturb the running applications, e.g., through a serial bus of the MPS.The use of the serial bus may not interfere with the runningapplications since they may use a different routing fabric (e.g., theinterconnection network) for their communication needs.

When swapping in an application, instructions and data for each of theapplication's tasks are moved into the appropriate memories on the MPS.In various embodiments, different mechanisms may be used for thistransport, e.g., depending on the particular communication resourcesavailable on the MPS. In some embodiments, the instructions and data maybe moved from their original storage locations to the appropriateon-chip memories through a high-speed routing fabric (also referred toherein as an interconnection network) implemented by the MPS. In otherembodiments the instructions and data may be moved to the appropriateon-chip memories through a serial bus. Using the high-speed routingfabric may be significantly faster than using a serial bus.

When using the routing fabric, the swapping system may define a familyof temporary “swapping routes” (one for each memory into whichinstructions and/or data are loaded) that is used for swapping. Usingthe communication routing fabric for moving the instructions and datamay require ensuring that the swapping routes do not interact or collidewith the communication routes being used by the other applicationsexecuting on the MPS. Consequently the swapping routes used to load theinstructions may be planned carefully to not intersect with these othercommunication routes.

To help in this planning, each swapping route may be divided into twoparts. The first part, referred to as the trunk route, is shared betweenall the swapping routes for the application. The trunk route connectsfrom the instruction and data storage location to a location on the MPSin the general vicinity where the application will reside. The secondpart of the swapping routes, referred to as the ending routes, mayconnect the endpoint of the trunk route to the target memory devicesused by the application. Thus, each swapping route may have a trunk partwhich is the same as all the other swapping routes for the application,and a unique ending route that goes from the endpoint of the trunk routeto a particular memory device. In some embodiments, the user may alsodivide the memories used by the application into multiple sets, and arespective trunk route may be defined for each set. This may be usefulfor example if the application is very large and uses many differentmemory devices.

In some embodiments, the trunk route may be specified by user input, andthe system software tools may then automatically define the second partof each swapping route. One advantage of using a trunk route is that theuser can carefully define the route to avoid routes used by otherrunning applications.

Some systems may have more than one routing layer for routing so thatthe trunk route can change layers as necessary to avoid other activeroutes. In some embodiments the system software tools may always use thefirst layer when generating the ending parts of the swapping routes soas to not interfere with any second-layer routes that reside in theswapping area of the MPS.

As noted above, moving instructions through the serial bus may besignificantly slower than through the routing fabric. However, it may bedesirable to use the serial bus to move instructions in situations wherespeed is not important and reducing the use of routing fabric resourcesis important. By definition, the master task may own the serial bus sothat there cannot be any conflicts over access to it. In someembodiments, the serial bus could be used when the instructions arestored in an external flash memory device, or when instructions arestreamed from the GPP into a port that is adjacent to the master task.

In some embodiments the MPS may include multiple chips, e.g., where eachchip includes a plurality of processors and a plurality of memoriesinterspersed among the processors. When application swapping is beingused with multiple-chip systems, the dedicated application swappingresources described above may be duplicated on each chip, in someembodiments. Application instruction storage may be split into multipleDRAMs, or multiple streams of instruction may be employed as necessary.In addition, the system controller may be designed to understand themulti-chip system, e.g., in order to have knowledge of where thecomponents reside in order to send commands to the proper chip.

In some embodiments, a swappable application may be distributed acrossmultiple chips in the system, although it may simplify the swappingprocess to require that each swappable application run on only one chip.

In some embodiments, multiple applications can be swapped at the sametime if there are multiple sources of independent data streams availableto the system. For example, FIG. 21 illustrates an embodiment in whichtwo applications 9A and 9B are swapped in simultaneously from twodifferent RAM devices 272A and 272B. Two different loader tasks mayexecute on the load PEs 274A and 274B to simultaneously load the twoapplications via the IO ports 274A and 274B onto the MPS. Swapping inmultiple applications simultaneously may enable the MPS to bereconfigured faster than if the applications were swapped in one at atime. The number of applications that can be swapped in or outsimultaneously may depend on the number of external memory devices orsources of instruction streams the MPS is coupled to. For example, ifthe package for the chip has connections for four DRAMs, up to fourapplications could be swapped at the same time.

In some embodiments, the master task 55 may only run one thread at atime. The swapping procedures may be constructed such that the mastertask 55 can manage multiple swapping procedures running at the sametime. For example, the most time-consuming part of swapping often willbe moving the instructions from the DRAM or I/O port to the instructionmemories of the application PEs. The master task 55 could simultaneouslyinstruct the loader tasks next to the I/O ports to begin movinginstructions. The other less time-consuming swapping steps could be doneserially by the master task.

Multiple streams of instructions could also be used to swap in a singleapplication in order to load the application faster. For example,instructions for an application being swapped in could be stored in twodifferent external DRAM devices, and two different streams ofinstructions could initialize the application PEs in parallel, therebyhalving the time to load the application.

Life Cycle of a Swappable Application

While the MPS is running, a given application may transition through anumber of steps to first swap in, then execute, then stop executing, andthen swap back out. The swappable application may go through thisprocess many times. FIG. 22 illustrates the life cycle of swapping anapplication in and back out. The master task may be responsible forcontrolling the sequence of steps. Some steps may be done in a slightlydifferent order in a given circumstance, or not be done at all.

In some cases, there could be a one-time initialization step to executesystem-level functions that is done when the system is reset. Forexample, an I/O port that is used by many different swappableapplications could be initialized, or application data initializationscould be written to external DRAMs. Starting from a system that has beenreset, a “Swap in Application” event may be received by the master task,as shown in 311. This event may be received internally from the MPS,e.g., from another application, or may be received as an externalsignal, e.g., from the system controller executing on the GPP externallyfrom the MPS.

The master task 55 may then cause the variables for the applicationbeing swapped in to be initialized and/or cause the previous state ofthe application (if it was previously saved) to be restored, as shown in313. The variable initializations (if any) may be derived from theprogram code for the application, e.g., from C program code in someembodiments. If any of the variable states for the application'svariables were previously saved (e.g., from a previous execution of theapplication) then the variable states may be loaded. This may restorethe application to its saved state. The saved variable states mayoverride the initializations derived from the application's programcode. The initialization and state restoration of the applicationvariables may be done by storing information specifying the variablevalues in one or more of the memories used by the application.

As shown in 315, the master task 55 may also cause the programinstructions of the application to be loaded into the correspondinginternal MPS memories associated with the application (if they are notalready loaded), e.g., by loading them from one or more external DRAMdevices or other external sources. After the instructions have beenloaded, the application PEs assigned to execute the instructions may beput into a wait state.

As shown in 317, the master task 55 may also handle the coupling of theapplication's communications to one or more of the other applicationsthat are loaded in the MPS, e.g., may enable the application to begincommunicating with each of the other applications that it needs tocommunicate with in order to perform the application's intendedfunction. The master task 55 may also initialize devices or resourcesthat are used by the application, such as I/O ports, DRAM ports, etc.and/or perform any operations necessary to cause the application toconnect to these devices and resources. The master task 55 may alsoinitialize the DRAM devices, DRAM contents, and devices connected to I/Oports used by the application (if needed).

The master task 55 may then start the application, as shown in 319. Forexample, the master task 55 may send a wakeup signal to each of theapplication's PEs to cause them to begin executing their respectiveprogram instructions from their associated memory devices. Once started,the application may continue running (block 321) until the master task55 receives a “Swap out application” event (block 323). In someembodiments the application itself may send the master task 55 a signalindicating that it has finished executing and can thus be swapped out.In other embodiments the master task 55 may receive the swap out eventfrom another application executing on the MPS, or from the systemcontroller 262 or other external source.

In response, the master task 55 may stop the application from executing,as shown in 325. For example, the master task 55 may send a stop signalto each of the application's PEs to cause them to stop executing. Insome embodiments the signal may also cause the PEs to reset to a knownstate.

As shown in 327, the master task 55 may cause the application to bedisconnected from the other applications and devices that it waspreviously connected to when it was loaded. This may include terminatingthe communication pathways between the application and any otherapplications it was coupled to. The master task 55 may also perform anyoperations necessary to shut down or reset the peripheral devices orother resources in use by the application.

As shown in 329, the master task 55 may also manage the process ofsaving the application's state. For example, the values of all theapplication's variables, or the values of a selected subset of theapplication's variables whose state needs to be saved, may betransmitted from one or more of the internal MPS memories to one or moreexternal RAM devices or other external memory devices for externalstorage until needed again. The contents of registers that correspond tothe application's variables may also be saved.

As shown in 331, the master task 55 may also perform one or moreoperations to cleanup the internal resources of the MPS. For example,this may include resetting all the internal memories used by theapplication. At the conclusion of this process the PEs, memories, androuting segments that had been used by this application will be ready tobe used for some other purpose.

It is noted that not all of these steps may need to performed, e.g.,depending on the particular application. For example, FIG. 23illustrates a simplified life cycle for an application that only need toconnect to I/O ports, and does not need to communicate with otherapplications or save its state between executions.

Executable Components Created to Implement Swapping

As illustrated in FIG. 24, a set of software tools 401 may be providedfor the MPS to generate the software code needed to implement theapplication swapping techniques described herein. The tools 401 mayinclude a compiler 403 configured to compile the source code of theapplications into executable program instructions, as well as one ormore procedure generation modules 405. The procedure generation modules405 may be configured to automatically generate executable softwareprocedures that will be executed at runtime to implement the swappingprocess. For example, the procedures may execute to perform operationsinvolved in the application swapping, such as loading the application'ssaved state, initializing devices used by the application, etc. Theseprocedures may only be created as needed. For example, a particularapplication may not save or restore its state, so the correspondingprocedures for these operations may not be created in this case. Some ofthe created procedures may be executed by application tasks, some by theloader task (if it exists), and some by the master task. The task thatexecutes each procedure may be determined based on the proximity to theresources being accessed and the configuration of the MPS. In someembodiments, the overall sequencing of these procedures is managed bythe master task.

According to some embodiments, procedures to perform the followingoperations may be automatically generated by the procedure generationmodules 405 prior to runtime, and then executed at runtime by the loadertask: initialize variable values derived from the application'sunderlying program code; load the application's executable programinstructions; and load the application's saved state.

According to some embodiments, procedures to perform the followingoperations may be automatically generated by the procedure generationmodules 405 prior to runtime, and then executed at runtime by theapplication tasks: initialize I/O and DRAM ports; initialize the DRAMcontroller and peripheral I/O devices (these DRAMs and I/Os are used bythe application and not used for swapping); and shut down the peripheralI/O devices.

According to some embodiments, procedures to perform the followingoperations may be automatically generated by the procedure generationmodules 405 prior to runtime, and then executed at runtime by the mastertask: couple application to neighboring applications; start theapplication (take PEs out of wait state); stop the application; decouplethe application from neighboring applications; save the applicationstate to the DRAM; and cleanup the internal MPS memories and routingfabric.

Layout and Development of Swappable Applications

In some embodiments, the applications that execute on the MPS may beclassified into two sets. One set of applications is referred to as thebase system. The base system includes one or more non-swappableapplications, e.g., applications that remain loaded and executing whilethe MPS is running. The other set is the set of swappable applicationsthat can be dynamically swapped in and out. Any time the MPS is running,the combination of swappable and non-swappable applications that areresident on the MPS are able to operate without interfering with eachother. Such a set of mutually non-interfering applications is called alegal configuration. A swappable application with a given layout andlocation on the MPS is called an application instance. Different layoutsor locations of the same swappable application are different applicationinstances because the same swapping code cannot be used for both. Forexample, one instance of the application may be deployed on one regionof the MPS and use one subset of the MPS's memories and PEs, and anotherinstance of the application may be deployed on another region of the MPSand use a different subset of the MPS's memories and PEs. The swappablecode may need to be specific to each instance, e.g., in order to loadthe application's instructions into the correct memories, communicatewith the correct PEs to start them running, etc.

A swappable MPS system can be seen as a system that transitions from onelegal configuration to another legal configuration as swapping eventsoccur. Swapping procedures cause transitions from one legalconfiguration to another. Such swapping procedures can include swappingin one or more applications and swapping out one or more otherapplications, adding or swapping in one or more applications to the MPS(e.g., without swapping out another application), and removing orswapping out one or more applications from the MPS (e.g., withoutswapping in another application). FIG. 25 illustrates an example of anMPS 300 where four applications 410A-410D are deployed on fourrespective regions of the MPS, as shown by the legal configuration A onthe left side. At some point while the MPS is running, a fifthapplication 410E may be dynamically added, resulting in a transition tothe new legal configuration B shown on the right side.

Each swapping procedure should be implemented so as to not interferewith the base system or other swappable applications not involved in theswapping procedure. FIG. 26 illustrates a development workflow that maybe used during the development phase of the system to construct sets ofapplications that are mutually non-interfering (legal configurations).

Each application may be developed and verified (block 412). Developingand verifying an application may include creating the application code,packaging the application in the form of an application cell,constructing a test bench for the application which instantiates theapplication cell and gives it placement and routing, and verifying theapplication cell using the test bench.

The set of applications that comprise each legal configuration may bedefined. The set of legal configurations and their transitions may beplanned (block 414).

A physical placement for each application instance may be defined (block416). All other application instances that border on the application'sperimeter (in any legal configuration) may be identified. The placementand routing for the application may be defined so as to avoid thebordering applications. In some embodiments, adjacent applications maynot share any of the MPS's internal memories because memory conflicts ina shared memory could cause timing issues for the applications. Also,the internal memories used by an application may be reset when theapplication is swapped.

As discussed above, if the internal memory in the MPS is limited so thatit cannot store the instructions for multiple applications, theninstructions will be moved into the MPS from outside the MPS viaswapping routes. The application's swapping should be defined so as tonot interfere with the border applications. Defining the swapping routesmay include defining a trunk route from the instruction source to thegeneral vicinity of the application instance such that the trunk routedoes not interfere with the border applications. Each of the swappingroutes for the application may use the trunk route as the first part ofthe swapping route. The swapping routes may then branch off from the endof the trunk route to the respective internal memories used by theapplication. The trunk route may be defined so as to not interfere withother border applications in every legal configuration in which theapplication instance is resident. FIG. 27 illustrates an example inwhich a plurality of swapping routes is being used to swap in anapplication 440D. The beginning part of each swapping route is the trunkpart 433 (indicated by the bold line) which originates from the I/O port437. The ending parts 435 (indicated by the dashed lines) of theswapping routes branch off from the ending point of the trunk route andcontinue on to individual memories located in the region of the MPS onwhich the application 440D is deployed. In various embodiments, anynumber of swapping routes may be used to load the program instructionsfor an application, e.g., depending on how many PEs and memories areused by the application.

Referring again to FIG. 26, the development workflow may also includechecking the layout of the constituent application instances for thelegal configurations to ensure that the respective application layoutsare compatible with each other. To check a given legal configuration, atop level test bench which instantiates all the application cells forthe configuration may be created. Placement and routing for eachapplication cell and for the connections between application cells andI/Os may be provided. The placement and routing of the combined set ofapplication cells may be checked to ensure that there are no conflictsover physical resources. In some embodiments the behavior of the entireconfiguration may be verified by simulating the configuration and thetest bench.

Communication Between Swappable Applications

As described above, swapping an application in or out may includecoupling or uncoupling communication between the application and one ormore other applications executing on the MPS (or between the applicationand one or more physical ports or peripheral devices). The communicationmay occur through the routing fabric of the MPS. When swapping out anapplication, the termination of the application's communications mayneed to be handled carefully so that the routing fabric is not left inan unusable state. For example, in some embodiments, if a swappableapplication is crudely terminated while sending a block of data toanother application, the existing routing may not be able to be easilyreused again until the system is reset.

In some embodiments, the applications executing on the MPS maycommunicate by passing data to each other through buffer memory devices.In some embodiments, each buffer memory device may be included in aspecial type of application cell referred to herein as an “isolatorcell.” In some embodiments, an isolator cell may have one input and oneoutput. The isolator cell may buffer the incoming data and then copy itto the output. The use of an isolator cell may provide a way for themaster task to break and restore connections between active applicationsin a reliable and consistent way. The MPS may contain many isolatorcells. FIG. 28 illustrates an example in which a swappable application460A communicates with another swappable application 460B by passingdata to the swappable application 460B via an isolator cell 464A. Theswappable application 460A also communicates with a non-swappableapplication 462 by passing data via another isolator cell 464B.

An isolator cell may be designed such that the master task can sendcommands through the serial bus to the isolator cell to cause theisolator cell to break the connection between two connected applicationsin preparation for swapping one of the applications out. After theapplication has been swapped out and a new one swapped in, the newapplication can be connected to the isolator to restore the flow of datain the system.

Different modes of operation are possible when the isolator cell breaksa connection between the applications. According to some embodiments,when the application on the downstream (receive) side of the isolatorcell is being swapped out, the default behavior of the isolator cell isto stop accepting data from the sending application once the connectionhas been broken. Any incoming data may back up in the routing fabric andeventually cause the sending application to stall. In an alternate mode,the isolator cell may continue to accept new data packets and simplyoverwrite the data packet in the isolator cell's memory buffer.

According to some embodiments, when the application on the upstream(send) side of the isolator cell is being swapped out, the defaultbehavior of the isolator cell is to stop forwarding data to thereceiving application once there is no more incoming data. In analternate mode, the isolator cell may continue to send data to thereceiving application by continually sending the existing data in theisolator cell's memory buffer over and over again. For example, it maysometimes be desirable to keep the data flowing so that the downstreamapplication will not go into a bad state or lock up.

It may simplify the swapping method if an isolator cell always existswhile any application is running on the MPS. It may be simplest if eachisolator cell exists in every legal configuration at exactly the samelocation. Using a fixed location may allow the swappable applicationsthat use the isolator cell to have a reliable physical location toconnect to, and may provide a reliable location for the master task tocommunicate with the isolator cell.

In more complex implementations, the isolator cell can be allowed to notexist in every legal configuration. For example, the isolator can beremoved (or moved) if both its upstream and downstream applications arebeing swapped out and if the new application(s) that are being swappedin do not use that isolator cell or use it in a different location.

In some situations it may be problematic to abruptly stop the flow ofdata between applications. For example, the data being transferred maycomprise data elements that have a certain structure. If thecommunication between the applications is cut off in the middle oftransmitting a given data element then the receiving application mayreceive only part of the data element and may not know how to handle thepartial data element. To overcome this problem, in some embodiments theisolator cell between the applications may have built-in knowledge ofthe data elements and may ensure that the communication is not cut offin the middle of transmitting a data element.

For example, consider a situation where a swappable application istransmitting video data to another application. Each frame of video datamay have a structure that starts with a header. The header may specifythe size of the frame. The header may be followed by a series of linesand line terminations, followed by a footer or tail. All the videoframes may be expected to have the same frame structure. Thus, thereceiving application may not be able to handle a partial frame. Theisolator cell may be enhanced to possess knowledge of the video framestructure so that it understands the data it is passing from the sendingapplication to the receiving application. When the isolator cellreceives a command to isolate the two applications while a transfer of aframe is in progress, it may not immediately terminate the transfer ofthe frame, but may instead continue the transfer until the rest of theframe has been transmitted. This may prevent the receiving applicationfrom receiving only a partial frame.

When a new application is swapped in, the new application may be coupledto the application(s) with which it communicates by configuring one ormore of the isolator cells in the MPS. For example, if the newapplication communicates with the same other application(s) as an oldapplication that was swapped out then the new application may be coupledto these other application(s) by controlling the same one or moreisolator cells involved in decoupling the old application from the otherapplication(s).

For example, the old application may have been on the downstream sidefrom a given isolator cell, and the isolator cell may have beendiscontinued from accepting data from a sending application when the oldapplication was swapped out. When the new application is swapped in, theisolator cell may be placed back in a mode of accepting data. Thus, whenthe execution of the new application is started, the data sent by thesending application may now be sent to the new application instead ofthe old application which previously received data from the sendingapplication.

As another example, the old application may have been on the upstreamside from a given isolator cell, and the isolator cell may have beendiscontinued from forwarding data to a receiving application when theold application was swapped out. When the new application is swapped in,the isolator cell may be placed back in a mode of forwarding data. Thus,when the execution of the new application is started, the receivingapplication may now receive data from the new application instead of theold application that previously sent data to the receiving application.

It is noted that the new application may also communicate with adifferent set of one or more applications than the old applicationcommunicated with. Thus, in some embodiments a different set of isolatorcells may be configured to couple the new application to its respectivecommunicant applications than were used for the communications of theold application.

Reliable Communication without Isolator Cells

Isolator cells may be especially useful in systems where the timing ofwhen the applications swap in and out is not reliably known. Employingisolator cells may allow breaking and killing a communication to beperformed reliably and keep the system in a known good state.

However, other embodiments that do not use isolator cells are alsocontemplated. For example, in some embodiments an application may bedesigned to reliably clean up its external communications. The cleanupmay be done in concert with the partner upstream or downstreamapplication. Applications can begin cleaning up their communications inat least two situations, e.g., when the application has completed itscomputation, and when the application has been commanded to transitionto a stable state and clean itself up.

In some embodiments, when the master task sends a command to theapplication, the communication mechanism between the application and themaster task can be a simple polling style API that uses one or moremailbox registers in each PE. This may be advantageous because it doesnot require all the PEs to have a means to directly communicate back tothe master task. As an example, the API may have the following twofunctions which can be called by swappable applications:

MPX_ready_to_swap( . . . )—The application has come to a stable stateafter cleaning up its external communication(s) and notifies the mastertask that it is ready to swap; and

MPX_check_for_stop_request( . . . )—The application checks if the mastertask has asked it to stop computing and come to a stable state.

A typical way this API could be used is that the master task may requestthe application to stop by sending a value to a mailbox register. Theapplication may receive the stop request by polling, e.g., by callingthe MPX_check_for_stop_request( . . . ) function at various times duringits execution. In response to the stop request, the application may stopand clean up its external communications. The application may thennotify the master task that it is ready to swap out by calling theMPX_ready_to_swap( . . . ) function, which sets a value in a mailboxregister. The master task may receive this notification by polling themailbox register.

The API could also be used if the application has independently finishedits calculation. For example, the application may stop and clean up itsexternal communications. The application may then notify the master taskthat it is ready to swap by calling the MPX_ready_to_swap( . . . )function. The master task may receive the notification by polling themailbox register.

The System Controller

In some embodiments the system controller program may provide thesystem-level control of application swapping. The system controller mayrun on a processor that is external to the MPS. In an exemplaryimplementation, the system controller runs on an externalgeneral-purpose processor and communicates commands to the master taskwhich then carries out those commands.

In some embodiments the system controller may be an application whichruns on the GPP and utilizes a subset of the Open Computing Language(OpenCL) host control API. The API subset provides functions formodeling the attached hardware system, starting and stoppingapplications, and moving data to and from embedded memory (for example,the DRAMs attached to the system).

The implementation of the OpenCL subset may be designed to be portableacross different GPPs so that a system controller program written for anARM processor could be ported to an x86 processor by simply recompiling.To do this the APIs should be implemented in two layers: the generic APIlayer, and the data communication layer. The data communication layermay be specific to a particular hardware platform and would be ported toany new hardware platform. One OpenCL capability is the support forexecuting native programs on attached compute engines.

Realizing a Swappable System

Once the logical and physical design and verification of the swappablesystem have been done, the object and information files necessary toexecute the design on the target system may be created. In someembodiments, this may be done as follows: 1) Create and verify the basesystem. 2) Create and verify all swappable applications. 3) Create andverify all legal configurations. 4) Create the database and object filefor the base system including the isolator cells. 5) Create executableswapping procedures for each unique application instance in each legalconfiguration. This may be repeated for each legal configuration untilswappable object files have been created for all application instances.6) Generate a master database for the entire set of applications. Thismay allow the system controller and master task to manage the set ofapplications during run time. 7) Compile the system controller programon the GPP.

Runtime Initialization

Running the swappable system may begin with the system controller. Thesystem controller may first load the master task and the loader tasks(if needed). The master task may then complete the following: 1) Runpre-boot initialization to initialize all resources such as DDRcontrollers and JO controllers. 2) Transfer object files for swappableapplications to DRAM(s) if required. 3) Load the base system includingall non-swappable applications and the isolator cells. 4) Wait forinstructions from the system controller. During runtime, the systemcontroller can control the state of the running system by sendingcommands to the master task.

Verifying a System Containing Swappable Applications

Individual applications may be independently verified in the usual wayby ensuring that they respond to stimuli correctly. Applications thatcommunicate with each other should be verified together, e.g., using thedevelopment workflow described above. Verification of all legalconfigurations should be done using normal software or hardwaretechniques for verifying a complete system.

Verification of the swapping procedure of a single application can alsobe done with a software simulator. This may be accomplished by defininga swappable system that solely consists of the single application andits associated test benches (as non-swappable applications). Then theentire swapping process including the master task and loader task can beexecuted and observed in the simulation environment. For verification ofthe application swapping mechanism, the system controller running on theGPP does not need to be simulated. The commands from the systemcontroller may be emulated via a data file which is streamed into theI/O port (or DAP port) during simulation or by creating an externalprogram that can statically or interactively emulate the temporalbehavior of the system controller.

Debugging a System Containing Swappable Applications

A number of different debugging tasks can be performed for a complexmulti-application swappable system. They may include:

1. Individual applications can be independently debugged as normalduring the application creation and verification process.

2. The swapping procedure for an individual application can be debuggedusing the procedure described above. Then the entire swapping processcan be executed and debugged in the simulation (or hardware debugging)environment including all the code in the master task and in the loadertask.

3. Debugging individual configurations can proceed by defining a toplevel configuration test bench for all the active applications and usingdebugging commands as needed. Since a stable configuration is beingdebugged, the simulator does not need to execute any applicationswapping steps and can run just the applications.

4. For debugging the complete swappable system, the debugger can loadthe complete project including the base system, isolator cells, and theapplication instances. At all times during the debugging session, thesimulator (or execution of the system on hardware) can keep track ofwhich application instances are swapped in, or are in the process ofswapping in or out. This information can be displayed to the user sothat the running applications are debuggable and the non-runningapplications are visible but not debuggable. This information can alsobe used to gather and display system statistics and to display thesystem-level swapping behavior.

When debugging a system of swappable applications, the debugger may havetwo options for the behavior of debugging commands (for example,breakpoints and single stepping). The first option may treat the entiredesign as a single system, and debugging commands can be applied to allactive applications in the design (for example, a breakpoint stops allapplications). The second option may allow each application to bedebugged independently. In this case, a breakpoint stops just theapplication it resides in. In addition, the debugger will provide theability to set breakpoints in applications that are currently swappedout. That way, when it is swapped in, the breakpoint is activeimmediately.

For debugging the system controller on the GPP together with the MPS,the debugger can provide an Eclipse-based development environment thatruns concurrently with the system development environment. The twodevelopment environments may be linked so that they share debuggingevents. For example, a breakpoint in the GPP could be defined to alsobreak the applications running on the MPS. Alternately, if the user doesnot want to debug the actual system controller, the debugger couldprovide a GPP emulator which can interactively or programmaticallyprovide a system controller command stream to the running system.

In various embodiments a computer-readable memory medium may storeprogram instructions executable by the processors of the MPS and/or oneor more external processors to implement various functions describedabove, such as functions involved in swapping software applications.Generally, the computer-readable memory medium may include any set ofinstructions which, when executed, implement a portion or all of thefunctions described herein. Generally speaking, a computer-readablememory medium may include any storage media accessible by a computerduring use to provide instructions and/or data to a computer system. Forexample, a computer-readable memory medium may include storage mediasuch as magnetic or optical media, e.g., disk (fixed or removable),tape, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, or Blu-Ray. Storagemedia may further include volatile or non-volatile memory media such asRAM (e.g. synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), staticRAM (SRAM), etc.), ROM, Flash memory, non-volatile memory (e.g. Flashmemory) accessible via a peripheral interface such as the UniversalSerial Bus (USB) interface, a flash memory interface (FMI), a serialperipheral interface (SPI), etc. Storage media may includemicroelectromechanical systems (MEMS), as well as storage mediaaccessible via a communication medium such as a network and/or awireless link. A carrier medium may include computer accessible storagemedia as well as transmission media such as wired or wirelesstransmission.

Although the system and method of the present invention has beendescribed in connection with the preferred embodiment, it is notintended to be limited to the specific form set forth herein, but on thecontrary, it is intended to cover such alternatives, modifications, andequivalents, as can be reasonably included within the spirit and scopeof the invention as defined by the appended claims.

What is claimed is:
 1. A method for performing application swapping in amultiprocessor system, the method comprising: loading a plurality ofapplications on the multiprocessor system, wherein the multiprocessorsystem comprises a plurality of processors and a plurality of memoriesinterspersed among the processors, wherein said loading comprisesdistributing instructions and data from the plurality of applicationsamong different respective ones of the plurality of memories forexecution by associated processors; executing the plurality ofapplications on the multiprocessor system, wherein the plurality ofapplications execute together and communicate with each other to performa real time operation, wherein the real time operation performs at leastone of input or output with real time data, wherein the plurality ofapplications process the real time data, wherein the plurality ofapplications comprise a first application and a plurality of otherapplications; swapping the first application with a second application,wherein the second application is not one of the plurality ofapplications that was previously loaded and executing on themultiprocessor system, wherein said swapping is performed withoutstopping the plurality of other applications, wherein the plurality ofother applications continue to execute during said swapping to performthe real time operation and process the real time data; wherein aftersaid swapping, the plurality of other applications continue to executewith the second application, and wherein at least a subset of theplurality of other applications communicate with the second applicationto perform the real time operation and process the real time data;wherein said swapping includes loading the second application into twoor more of the memories, wherein said loading comprises sending programinstructions of the second application through the multiprocessor systemalong two or more swapping routes, wherein each of the swapping routesis associated with one of the two or more memories; and wherein the twoor more swapping routes share a first part in common, wherein the firstpart includes a route from an I/O port of the multiprocessor system toan endpoint within the multiprocessor system, and wherein the first partis specified by user input.
 2. The method of claim 1, wherein prior tosaid swapping, the first application executes on a first subset of theplurality of processors; wherein said swapping comprises: stopping thefirst application on the first subset of the plurality of processors;saving a state of the first application; and loading the secondapplication into memories associated with the first subset of theplurality of processors.
 3. The method of claim 2, wherein said swappingfurther comprises: decoupling communication of the first applicationwith one or more of the other applications.
 4. The method of claim 3,wherein one or more first buffer memories are coupled between the firstsubset of the plurality of processors and other ones of the plurality ofprocessors; wherein said decoupling communication of the firstapplication comprises controlling the one or more first buffer memoriesto enable the decoupling.
 5. The method of claim 3, wherein saidswapping further comprises: after said loading the second application,coupling communication of the second application with the one or more ofthe other applications.
 6. The method of claim 3, wherein said swappingfurther comprises: prior to swapping in the second application,resetting the first subset of the plurality of processors to place thefirst subset of the plurality of processors in a known state.
 7. Themethod of claim 1, wherein the plurality of other applications are notaware that the swapping is occurring.
 8. The method of claim 1, whereinprior to said swapping, the first application executes on a first subsetof the plurality of processors; wherein said swapping further comprises:decoupling the first application from one or more external resources,wherein the external resources are external to the multiprocessorsystem; stopping the first application on the first subset of theplurality of processors; loading the second application into memoriesassociated with the first subset of the plurality of processors; andafter said loading the second application, coupling the secondapplication to the external resources.
 9. The method of claim 1, whereinthe multiprocessor system comprises a plurality of buffer memoriesinterspersed among at least a subset of the plurality of processors;wherein said swapping comprises altering communication performed by afirst buffer memory at least one of to or from the first applicationduring said swapping.
 10. The method of claim 9, wherein the firstapplication is on a downstream side of the first buffer memory, whereinsaid altering comprises discontinuing the first buffer memory fromaccepting data from a sending application during said swapping.
 11. Themethod of claim 10, wherein said altering further comprises the sendingapplication stalling in response to the first buffer memorydiscontinuing accepting data from the sending application.
 12. Themethod of claim 9, wherein the first application is on a downstream sideof the first buffer memory, wherein said altering comprises configuringthe first buffer memory to continue accepting data from a sendingapplication and to overwrite previously stored and unsent data duringsaid swapping.
 13. The method of claim 9, wherein the first applicationis on an upstream side of the first buffer memory, wherein said alteringcomprises discontinuing the first buffer memory from forwarding data toa receiving application during said swapping.
 14. The method of claim13, wherein said altering comprises discontinuing the first buffermemory from forwarding data to the receiving application once there isno more incoming data from the first application.
 15. The method ofclaim 9, wherein the first application is on an upstream side of thefirst buffer memory, wherein said altering comprises configuring thefirst buffer memory to repeatedly send its data to a receivingapplication two or more times during said swapping.
 16. The method ofclaim 1, wherein the multiprocessor system comprises a plurality ofbuffer memories interspersed among at least a subset of the plurality ofprocessors, wherein prior to said swapping the first applicationcommunicates structured data elements via a first buffer memory, whereineach data element has a beginning boundary and an ending boundary;wherein said swapping comprises: the first buffer memory receiving arequest to discontinue data communication after transmission of a firstdata element has been initiated; and the first buffer memory continuingtransmission of the first data element up to the ending boundary of thefirst data element.
 17. The method of claim 1, wherein prior to saidswapping, the first application executes on a first subset of theplurality of processors; wherein said swapping comprises loading thesecond application from an external memory device into memoriesassociated with the first subset of the plurality of processors.
 18. Themethod of claim 1, wherein prior to said swapping, the first applicationexecutes on a first subset of the plurality of processors; wherein saidswapping comprises loading the second application from an instructionstream transmitted by an external processor outside the multiprocessorsystem into memories associated with the first subset of the pluralityof processors.
 19. The method of claim 1, wherein said swappingcomprises swapping the first application with a plurality of secondapplications simultaneously, wherein the plurality of secondapplications are simultaneously loaded into the multiprocessor systemfrom different source memory devices.
 20. The method of claim 1, whereinsaid swapping comprises swapping out the first application in responseto receiving information from one of the other applications executing onthe multiprocessor system, wherein the information indicates that thefirst application should be swapped out.
 21. The method of claim 1,wherein said swapping comprises swapping out the first application inresponse to receiving an external signal indicating that the firstapplication should be swapped out, wherein the external signal isreceived from outside the multiprocessor system.
 22. The method of claim21, wherein the external signal is received from a system controllerprogram that executes on a processor external to the multiprocessorsystem.
 23. The method of claim 1, further comprising: executing amanagement task on the multiprocessor system along with the plurality ofapplications, wherein the management task executes on one or more of theprocessors of the multiprocessor system, wherein the management task isconfigured to manage said swapping the first application with the secondapplication.
 24. The method of claim 1, wherein the second applicationincludes a plurality of executable tasks, wherein said swapping thefirst application with the second application comprises configuring eachof the tasks to be executed by a different processor of themultiprocessor system.
 25. The method of claim 1, wherein said swappingthe first application with the second application comprisessimultaneously transmitting two or more instruction streams to themultiprocessor system from two or more source memory devices external tothe multiprocessor system, wherein each instruction stream includesprogram instructions of the second application.
 26. A non-transitorycomputer readable memory medium storing program instructions, whereinthe program instructions are executable by multiprocessor system to:load a plurality of applications on the multiprocessor system, whereinthe multiprocessor system comprises a plurality of processors and aplurality of memories interspersed among the processors, wherein saidloading comprises distributing instructions and data from the pluralityof applications among different respective ones of the plurality ofmemories for execution by associated processors; initiate execution ofthe plurality of applications on the multiprocessor system, wherein theplurality of applications execute together and communicate with eachother to perform a real time operation, wherein the real time operationperforms at least one of input or output with real time data, whereinthe plurality of applications process the real time data, wherein theplurality of applications comprise a first application and a pluralityof other applications; and swap the first application with a secondapplication, wherein the second application is not one of the pluralityof applications that was previously loaded and executing on themultiprocessor system, wherein said swapping is performed withoutstopping the plurality of other applications, wherein the plurality ofother applications continue to execute during said swapping to performthe real time operation and process the real time data; wherein aftersaid swapping, the plurality of other applications continue to executewith the second application, and wherein at least a subset of theplurality of other applications communicate with the second applicationto perform the real time operation and process the real time data;wherein said swapping includes loading the second application into twoor more of the memories, wherein said loading comprises sending programinstructions of the second application through the multiprocessor systemalong two or more swapping routes, wherein each of the swapping routesis associated with one of the two or more memories; and wherein the twoor more swapping routes share a first part in common, wherein the firstpart includes a route from an I/O port of the multiprocessor system toan endpoint within the multiprocessor system, and wherein the first partis specified by user input.
 27. The non-transitory computer readablememory medium of claim 26, wherein prior to said swapping, the firstapplication executes on a first subset of the plurality of processors;wherein said swapping comprises: stopping the first application on thefirst subset of the plurality of processors; saving a state of the firstapplication; and loading the second application into memories associatedwith the first subset of the plurality of processors.
 28. Thenon-transitory computer readable memory medium of claim 27, wherein saidswapping further comprises: decoupling communication of the firstapplication with one or more of the other applications.
 29. Thenon-transitory computer readable memory medium of claim 27, wherein saidswapping further comprises: after said loading the second application,coupling communication of the second application with the one or more ofthe other applications.
 30. The non-transitory computer readable memorymedium of claim 26, wherein the multiprocessor system comprises aplurality of buffer memories interspersed among at least a subset of theplurality of processors; wherein said swapping comprises alteringcommunication performed by a first buffer memory at least one of to orfrom the first application during said swapping.
 31. The non-transitorycomputer readable memory medium of claim 26, wherein prior to saidswapping, the first application executes on a first subset of theplurality of processors; wherein said swapping comprises loading thesecond application from an external memory device into memoriesassociated with the first subset of the plurality of processors.
 32. Amultiprocessor system, comprising: a plurality of processors; aplurality of memories interspersed among the processors; a communicationfabric interconnecting the plurality of processors and the plurality ofmemories interspersed among the processors, wherein the communicationfabric comprises a plurality of buffer memories interspersed among atleast a subset of the plurality of processors; wherein the plurality ofbuffer memories are configurable to communicate data betweenapplications executing in the multiprocessor system; wherein, duringexecution of a plurality of applications on the multiprocessor system toperform a real time operation that includes receipt and/or transmissionof real time data and processing of the real time data, the plurality ofbuffer memories are configurable to break and restore connectionsbetween active applications during swapping of a first application witha second application; wherein said swapping comprises loading the secondapplication into two or more of the plurality of memories, wherein saidloading comprises sending program instructions of the second applicationthrough the multiprocessor system along two or more swapping routes,wherein each of the swapping routes is associated with one of the two ormore memories; and wherein the two or more swapping routes share a firstpart in common, wherein the first part includes a route from an I/O portof the multiprocessor system to an endpoint within the multiprocessorsystem, and wherein the first part is specified by user input.
 33. Themultiprocessor system of claim 32, further comprising: a plurality ofdata memory routers (DMRs) coupled between the plurality of processors,wherein the DMRs include the plurality of memories interspersed amongthe processors.
 34. The multiprocessor system of claim 32, wherein thefirst application is on a downstream side of a first buffer memory,wherein the first buffer memory is configurable to discontinueacceptance of data from a sending application during said swapping. 35.The multiprocessor system of claim 32, wherein the first application ison a downstream side of a first buffer memory, wherein the first buffermemory is configurable to continue accepting data from a sendingapplication and to overwrite previously stored and unsent data duringsaid swapping.
 36. The multiprocessor system of claim 32, wherein thefirst application is on an upstream side of a first buffer memory,wherein the first buffer memory is configurable to discontinueforwarding data to a receiving application during said swapping.
 37. Themultiprocessor system of claim 32, wherein the first application is onan upstream side of a first buffer memory, wherein the first buffermemory is configurable to repeatedly send its data to a receivingapplication two or more times during said swapping.
 38. Themultiprocessor system of claim 32, wherein prior to said swapping thefirst application communicates structured data elements via a firstbuffer memory, wherein each data element has a beginning boundary and anending boundary; wherein in response to initiation of said swapping thefirst buffer memory is configurable to: receive a request to discontinuedata communication after transmission of a first data element has beeninitiated; and continue transmission of the first data element up to theending boundary of the first data element.